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AUTOMATED BUSINESS MACHINE MANAGEMENT 

This application claims the benefit of U.S. Provisional Patent Application 
No. 60/225,369 filed on August 14, 2000. 

BACKGROUND OF THE INVENTION 
5 This invention relates in general to business machines and, more 

specifically, to managing business machines. 

Business machines such as copiers, printers, fax machines, scanners, and 
multi-function devices are integral to any business operation. Service and supplies are 
needed to maintain proper operation of these business machines. An office worker 
1 0 typically makes the service calls and orders supplies for the business machine, which is a 
laborious process. 

Maintenance contracts often cover service calls for business machines. 
These maintenance contracts may run for a period of time or a number of copies, prints, 
faxes, and/or scans. The business machine may include an external or internal device that 
1 5 monitors some operation of the business machine. A meter on this device is read each 
month, or some other period, and that reading is manually reported back to the 
maintenance organization. For example, a questionnaire may be sent to the office worker 
to add the meter reading and fax that questionnaire back. On that same questionnaire, the 
office worker may order supplies for the business machine. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is described in conjunction with the appended 

figures: 

FIG. 1 A is a block diagram of an embodiment of a business machine 
management system; 

2 5 FIG. 1 B is a block diagram of an embodiment of another business machine 

management system that has a combined wireless data center; 

FIG. 2 is a block diagram of an embodiment of a data capture device; 

FIG. 3 is a block diagram of an embodiment of an operations center 
coupled to a web interface; 



FIG. 4 is a flow diagram of an embodiment of a process for purchasing 
office equipment and/or supplies and/or selecting a service contract for any office 
equipment; 

FIG. 5 A is a flow diagram of an embodiment of a process followed for a 
5 pay-by-term service contract without supplies; 

FIG. 5B is a flow diagram of an embodiment of a process followed for a 
pay-as-you-go contract without supplies; 

FIG. 5C is a flow diagram of an embodiment of a process followed for a 
pay-as-you-go contract with supplies; 
1 0 FIG. 5D is a flow diagram of an embodiment of a process followed for a 

pay-in-advance contract without supplies; 

FIG. 5E is a flow diagram of an embodiment of a process followed for a 
pay-in-advance contract with supplies; and 

FIG. 6 is a flow diagram of an embodiment of a process for servicing an 
15 business machine. 

In the appended figures, similar components and/or features may have the 
same reference label. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
The ensuing description provides preferred exemplary embodiment(s) 

20 only, and is not intended to limit the scope, applicability or configuration of the invention. 
Rather, the ensuing description of the preferred exemplary embodiment(s) will provide 
those skilled in the art with an enabling description for implementing a preferred 
exemplary embodiment of the invention. It being understood that various changes may 
be made in the function and arrangement of elements without departing from the spirit 

25 and scope of the invention as set forth in the appended claims. 

The present invention provides a system and method for automating 
service contracts for business machines. In one embodiment, a data capture device is 
associated with the business machines in the system. Each data capture device is loaded 
with one or more threshold events corresponding to a supplies and/or service contract for 

30 the associated business machine. When a threshold event is triggered a message, bill, 
service call, etc. is automatically generated. Service calls are automatically scheduled 
and dispatched by the system after they are reported. In some cases, the data capture 
device automatically initiates the service call. 

2 



Referring initially to FIG. lA, a block diagram of an embodiment of a 
business machine management system 100 is shown. This embodiment automates 
interaction between the system 1 00 and customers when configuring service contracts and 
maintaining a business machine 112 covered by that service contract. Billing of service 
5 contracts and scheduling service orders is automated in this embodiment, such that only a 
user and a technician need normally interact with the management system 1 00. 

A client computer 136 with a web browser or equivalent logs onto a wide 
area network 128 such as the hitemet. The web browser pulls down web pages from a 
web interface 108. These web pages allow buying or leasing a piece of business 

10 equipment 112. Copiers, fax machines, printers, scarmers or multi-function devices that 
perform at least twoof the forgoing functions are considered business equipment 1 12 
regardless of whether those machines are used at a business. Additionally, the web pages 
allow interaction with billing and service functions. Some information, such as bills and 
supply orders, are available from the web interface as well as electronic message formats 

15 such as e-mail, instant messaging, WAP messaging, etc. 

The web interface 108 serves as the user interface (UI) to the operations 
center 104. Management of the system 100 is performed by the operations center 104. 
Service scheduling, message processing, billing, data mining, and database storage are 
just some of the major fixnctions of the operations center 104. By communicating over 

20 the Internet 128 or some other network, the operations center 104 arbitrates payment for 
business machines 112 and service contracts. 

A number of electronic payment organizations 132 provide payment in the 
conventional maimer. Examples of electronic payment organizations include credit card 
companies, debit card companies, banks, and bill payment services. 

25 A number of business machines 1 12 are communicating with a respective 

data capture device 1 16 to facilitate management by the system 100. Each business 
machine 112 under a service contract is issued a data capture device 116 such that there is 
a data captxxre device 1 16 for each business machine 1 12 capable of interfacing with the 
data capture device 116. Where a data capture device 1 16 is not issued, manual readings 

30 from the business machine 112 are performed. 

The data capture device 116 logs events reported from the business 
machine 1 12 and includes threshold events that trigger communication back to the 
operations center 104. The threshold events could include errors detected, usage counts, 
tamper detection, power loss or predetermined time periods. In this embodiment, the 



operations center 1 04 determines the threshold events and programs the data capture 
device 116 remotely, but some embodiments could enter some of the threshold events by 
direct connection to the data capture device 116. 

The data capture devices 1 16 wirelessly communicate via a pager channel 
5 to the pager data center 118. Other embodiments of data capture device 1 1 6 could use 
cellular data, satellite, personal communication service, wireless networking, or other 
wireless data communication technologies to communicate with the operations center 
104. This embodiment uses a Motorola'^'^ pager module with SkyTeF"^ providing nation- 
wide paging service. Any conmiunication with the pager is carried by the pager data 

10 center 1 18 to and from the operations center 104 using the wide area network 128. 

The operations center 104 also wirelessly communicates with wireless 
application protocol (WAP"^") service terminals 124. Each service technician is issued a 
service terminal 124 that could be any portable device with wireless data communication, 
for example, a WAP enabled phone, a pager or a PDA with wireless capability. The 

15 WAP data center 112 interfaces to the wide area network 128 to convert messages for 
wireless transport between the network 128 and the WAP service terminal 124. 

With reference to FIG. IB, a block diagram of an embodiment of another 
business machine management system 150 is shown that has a combined wireless data 
center 120. This wireless data center 120 communicates with both the WAP service 

20 terminals 124 and the data capture devices 116. For example, the data capture device 

could include a WAP module for this communication. Each data capture device 1 16 and 
each WAP service terminal 124 is addressable to properly route traffic to and from the 
operations center 104. 

Referring next to FIG. 2, a block diagram of an embodiment of a data 

25 capture device 1 16 is shown. Information is collected and reported by the data capture 
device 1 16 to the operations center 104. Threshold events are loaded in the data capture 
device 116 from the operations center 104. These threshold events may include 
requirements resulting from the service contract chosen by the user. Included in the data 
capture device 1 16 are a data processor, a business machine interface 208, a wireless data 

30 hnk 212, and a service call button 216. 

Service calls can be initiated in a number of ways, but one way is by way 
of the service call button 216. Activation of this button causes a service call to be issued 
to the operations center 104. Some embodiments may integrate this function into the 
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business machine 112 such that the existing interface to the business machine 112 can be 
used to initiate the service call. 

In this embodiment, the wireless data link is a two-way pager module 
available from Motorola™, but any wireless data link could be used. Different modules 
5 may be used in different geographic locations as dictated by the wireless data services 
available. Some embodiments of the data capture device 116 use a modular approach 
such that the wireless data link 212 is easily interchangeable. Where the data link is 
limited to messages of a limited size, messages sent by the data processor may span a 
number of wireless messages. 

1 0 The data capture device 116 interfaces with an associated business 

machine 112 using the interface 208. Most business machines have some sort of interface 
port and typically this port uses a serial protocol. The business machine interface 208 
could be a simple connector adapter or could include circuit elements dictated by the 
interface to the business machine 1 12. In some cases, the business machine 1 12 does not 

1 5 have an interface port such that the business machine interface 208 may include sensors 
to collect usage counts and other information for the data processor 204. The business 
machine interface 208 is modular such that it may be easily interchanged such that the 
data capture device 116 can accommodate a number of different business machines 112. 

The data processor 204 interacts with the business machine interface 208 

20 to provide status information to the operations center 104. The protocol used by the 

business machine 112 may be translated by the data processor 204. The data processor 
204 is configured to understand the protocol of the business machine 112. Threshold 
events are downloaded to the data processor 204 such that when the threshold is crossed, 
a trigger activates some action. For example, the data processor 204 may send a message 

25 to the operations center 104 when a service contract is about to expire. Further 

information can be gathered by the operations center 104 by polling the data processor 
204 for that information. Use of threshold events in this embodiment, allows avoiding the 
need to poll the data processor 204 more frequently. 

Error conditions in the business machine 112 that require service are 

30 determined by the data processor 204. A communication to the operations center 104 

initiates a service call to a technician. Status information related to the service call can be 
included in the service call such that the technician has a description of a purpose for the 
service call. The operations center 104 can wirelessly issue these service calls to 
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technicians without a need for human interaction to automate the service call and improve 
response times. 

With reference to FIG. 3, a block diagram of an embodiment of an 
operations center 104 coupled to a web interface 108 is shown. A computer system 304 
5 with a wide area network interface runs applications such as a billing function 324, a 
messaging function 308, a service scheduling and dispatch function 312, a supply 
management fimction 316, a data mining function 328, a business machine database 320, 
a technician database 336, and a customer database 332. Those skilled in the art 
appreciate that these applications could run on any number of computers in the computer 
10 system 304 where the computers have any number of configurations. Further, the 

applications could be located in disparate locations that are coupled together with a wide 
area network 128. 

The billing function 324 performs billing to all the users of the system 100. 
Purchases, leases and service contract expenses are collected by the billing function 324 

15 from the appropriate electronic payment organization 132 authorized by the user. From 
the web interface 108, the user enters the information necessary to enable the payment 
transfer for the expenses incurred. Some expenses, such as business equipment 
purchases, supplies purchases and pay-for-term service contracts, result in a single billing 
transaction while others, such as business equipment leases, pay-as-you-go service 

20 contracts and pay-in-advance service contracts, result in recurring billings. The 
reoccurring billings may be preauthorized or request reauthorization each time. 
Reauthorization requests are automatically generated whereafter the user manually 
provides authorization through the web interface 108 or another automated interface. In 
some embodiments, a user may be billed for any charges from the system 100, 

25 whereafter, the user can pay the invoice with a check or other conventional payment 
method. 

The messaging function 308 facilitates communication to the wireless data 
center(s) 120 that communicates with the WAP service terminal 124 and the data capture 
device 1 16. Any formatting, translation and/or handshaking are performed to convey the 
30 messages to and from the wireless data center 120. The messaging function 308 may 
support any number of wireless data centers 120 that are used in various geographic 
locations. A query to the customer database 323 allows determining the type of wireless 
data center 120 used to communicate with a particular destination. 
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Service calls are managed by the service scheduling and dispatch function 
312. A service call may be initiated from the web interface 108, a call to customer 
service, the service call button 216, or a condition detected by the data processor 204. 
However the service call is begun, the scheduling and dispatch function 312 is referenced 
5 to determine the technician and time for handling the service call. The technician 

database 336 is referenced to determine the qualified technicians capable of adequately 
servicing the service call for the particular business machine 112. This determination 
may involve analysis of the type of service call, the technicians available, the technicians 
that have serviced the business machine before, and other factors. A message is sent to 
1 0 the selected technician that describes the service call along with contact information for 
the user retrieved from the customer database 332. The technician will perform the 
service call and report any results that are wirelessly transmitted back to the scheduling 
and dispatch function 312. The service call and resolution are noted in the machine 
database 320. 

15 Some service contracts include supplies for the business equipment 112 

such as toner, ink, paper, cleaning supplies, etc. The data capture device 116 records use 
of the business machine 11 2 and records use of consumables in the machine database 
320. In some circumstances, the supply management function 316 predicts when supplies 
will be needed and automatically ships them to the user at business machine location. In 

20 other circumstances, an electronic message is sent to the user asking for information on 
the supplies such that verification is made before shipping out more supplies. 

In any event, the user can log onto the web interface to order supplies 
regardless of whether they are included in a contract. If there is no supply contract, the 
user is billed for any supplies ordered. When supplies are requested that are included in 

25 the supply contract, a check is made to determine if the amount of supplies used is within 
an allowable range for the business machine 112 given the usage reported by the data 
capture device 1 16. In this way, abusers of the supply contract can be detected. All 
supply usage is recorded in the machine database 320. 

There are three databases 320, 332, 336 in this embodiment of the 

30 operations center 104. Those skilled in the art appreciate that the databases 320, 332, 336 
could be combined or separated in any logical maimer and may run on one or more 
computers in one or more locations. A data mining function 328 allows determining 
relationships between the data stored in the databases 320, 332, 336. For example, a 
manufacturer may want to know the number of service calls for a particular model of 



business machine. Information such as this can be used to determine the pricing for the 
service contracts or determine when preventative maintenance is advisable. 

The customer database 332 stores information about the user of the 
business machine 112. In most organizations, a contact person is typically assigned to 
5 manage the business machines 1 12. This person is recorded in the customer database 332 
along with ways to contact this person electronically, in-person and over the phone. In 
addition to contact information, account information is entered by the contact person into 
the web interface, such as electronic payment information. Also the customer database 
lists all the business machines 112 associated with that user. 

10 In the technician database 336, information on the technicians available to 

the management system 100 is stored. Each technician has qualifications for various 
business machines 1 12 stored in this database 336. The current schedule and current 
location of each technician is also recorded in the technician database along with contact 
information for the technician. For example, the type of wireless data center 120 the 

15 technician uses for electronic messages to the service terminal 124 is recorded in this 
database 336. 

The machine database 320 stores information related to a particular 
machine. This information includes the service records, the supply usage, unused 
supplies at the user location, the user associated with the business machine, etc. The 

20 service records include past service calls and their resolution, past preventative 

maintenance, scheduled preventative maintenance, etc. Some of the information in the 
machine database 320 is made available to the user by way of the web interface 108. In 
instances where the user bought the business machine 112 used, any information in the 
machine database 320 may be retained for the new user. 

25 Referring next to FIG. 4, a flow diagram of an embodiment of a process 

for purchasing office equipment 112 and/or supplies and/or selecting a service contract 
for any office equipment 1 12 is shown. The depicted process begins in step 402 where a 
determination of whether any items should be purchased by the user. Business machines 
112, options and supplies can be purchased by proceeding to step 404. Any business 

30 machine and options are selected in step 404. The user can lease or purchase the office 
equipment 112 and options in step 408. Other embodiments may allow renting of the 
office equipment 1 12 also. Where supplies are desired, they can be purchased in step 
410. Some service plans include supplies such that a user is unlikely to purchase supplies 
in step 410 where suppUes are part of the service contract. 



If no service plan is desired in step 412, the customer enters payment 
information and the electronic payment organization is debited for the amount owed in 
step 414. Once pajnnent is taken care of, the purchases are shipped to the customer in 
step 416. If no service plan is desired in step 412, a data capture device 1 16 is not 
5 necessary in this embodiment. In some embodiments, a data capture device 116 could be 
included regardless of a service or supply contract. 

If a service plan is desired in step 412, processing continues to step 420 
where a service and/or supply contract is chosen. This embodiment allows selection of 
five different contracts: pay-by-term service contract without supplies (see FIG. 5A), pay- 

10 as-you-go service contract without supplies (see FIG. 5B), pay-as-you-go service contract 
with supplies (see FIG. 5C), pay-in- advance service contract without suppHes (see FIG. 
5D), and pay-in-advance service contract with supplies (see FIG. 5E). Other 
embodiments, may limit the types of contracts available based upon the model of business 
machine 1 12 covered by the contract. For example, a scanner would not normally need 

15 any supplies so contracts that provide suppUes could be excluded at step 420. Selection 
of the type of contract dictates which of FIGS. 5A-E will continue the process as 
respectively described below. 

With reference to FIG. 5 A, a flow diagram of an embodiment of a process 
followed for a pay-by-term service contract without supplies is shown. A pay-by-term 

20 service contract allows buying service in advance for a predefined period. This 

embodiment does not provide for supplies to be included, but other embodiments could 
provide supplies. The depicted portion of the process takes-up in step 522 where a 
determination is made by the operations center 102 of whether there is a data capture 
device 1 16 already installed. The machine database 320 can be queried for this 

25 information and the data capture device 116 could be queried for further verification. A 
data capture device 116 will already be installed because the user is renewing their 
contract. 

Where no data capture device 116 has been installed, processing continues 
to step 524 where a data capture device 1 16 is registered to the customer and contract. 
30 The machine database 320 is updated to reflect the address of the data capture device 116, 
business machine serial number, business machine model, and wireless data center 120 
used for communication with the data capture device 116. The customer database 332 is 
also updated to reflect that the data capture device 116 is assigned to that customer. In 
step 528, the data capture device 116 is shipped to the customer for installation. Other 



embodiments could install the data capture device 116 prior to shipment to the customer, 
but in this embodiment, the customer installs the data capture device 1 16 in step 532. 
Further, a technician could install the data capture device 116 in some embodiments. 

Once power is applied to the data capture device 116, information is sent 
5 back to the operations center 104. The operations center 104 determines report-back 
thresholds in step 534. For example, when 85% or some other threshold percentage of 
the contract term has expired, the data capture device 116 will inform the operations 
center 104 of this. Other event thresholds could include changing of toner or ink, 
unplugging the business machine 112, opening of the business machine 1 12, error 

10 conditions detected, page counts being exceeded, activation of the service call button 216, 
etc. Different business machines 112 may support different features, such that the event 
thresholds may be customized for each business machine model and/or contract. 
Wirelessly, the event thresholds are loaded into the data capture device 1 16 in step 536. 

If any service condition is detected in step 540, a service call is started and 

15 processing continues to FIG. 6. A service condition is an error detected by the data 

capture device 116 that would warrant a service call. Alternatively, processing continues 
to step 544 if there is no service condition detected. If the threshold event of 85% of the 
pay-by-term contract expired is not satisfied in step 544 processing continues back to step 
540. Where the threshold event is triggered, processing continues to step 548 where the 

20 customer is electronically notified of the impending end of the contract period. The 
notification could be by e-mail, instant message, WAP message, web page notice, or 
other electronic notification methods. If the user desires to start a new contract in step 
552, processing continues back to step 420 of FIG. 4. In some embodiments, the user can 
select to make the renewal of the same type of contract automatic such that without 

25 intervention the same contract type will be renewed. 

Where a new contract is not desired in step 552, the term will expire in due 
course. A threshold event in the data capture device 116 notifies the operations center 
104 of the expiration of the contract in step 554. Service calls after expiration are not 
covered by the contract. Although the above embodiment relies upon the data capture 

30 device 116 for notification of contract threshold events, some embodiments could have 
the operations center 1 04 also track this information. For example, when the contract 
term is at 85%, a notification could be sent out regardless of any triggered report from the 
data capture device 116. 
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Referring next to FIG. 5B, a flow diagram of an embodiment of a process 
followed for a pay-as-you-go contract without supplies is shown. In a pay-as-you-go 
contract, the user pays in arrears for the service contract that may be tied to usage. For 
example, there may be a one cent charge for service per page printed so long as usage is 
5 under a thousand pages per month. Where usage exceeds a thousand pages per month, a 
half cent may be charged per page in excess of one thousand. In another example, the 
user may be charged a flat fee for the service contract of the last month regardless of 
usage. 

This embodiment presumes the business machine 1 12 does not have a data 

10 capture device 116 installed, but some embodiments could already have one installed. 

Steps 524, 528, 532, 534, 536, 540 largely operate as discussed in relation to FIG. 5A. In 
step 556, a threshold event programmed in step 536 is tested to see if the billing period 
has ended. If it has not ended processing loops back to step 540. 

Where the billing period threshold event is triggered in step 556, the 

15 operations center 104 is notified. Independently, the operations center 104 may detect 
expiration of the billing period. In some embodiments, the data capture device 1 16 is not 
programmed to report the end of the billing cycle. After the end of the billing period is 
determined in step 556, the data capture device is queried for usage in step 560, 

Pa5mient for the service contract over the prior billing period is performed 

20 in step 564. The billing function 324 uses the electronic pajonent information stored in 
the customer database 332 to get payment from the specified electronic payment 
organization 132. The electronic payment information could include a credit card, 
electronic funds transfer or other method of electronic payment. In some embodiments, 
an invoice may be issued in a conventional manner where a bill is electronically or 

25 mechanically issued and payment follows. Once the payment is collected, a billing 

notification is issued electronically in step 568, whereafter, processing loops back to step 
540. The electronic notification could be via an electronic message or a posting through 
the web interface 108. Further, some embodiments could issue a paper billing 
notification by mail. 

30 With reference to FIG. 5C, a flow diagram of an embodiment of a process 

followed for a pay-as-you-go contract with supplies is shown. This embodiment is 
similar to the embodiment of FIG. 5B except that supplies for the business machine 112 
are included in the service contract. New steps 572 and 580 and the repositioning of step 
560 accommodate the supply contract. 



After testing for a service condition in step 540, a determination is made in 
step 572 of whether supphes are needed. Determination of whether supplies may be 
needed is performed by the supply management function 316. In step 560, the data 
capture device is queried for usage at a predetermined interval, such as once a day. 
5 Additionally, some of the threshold events set in step 536 could include detection of 
paper, toner, ink or other consumables being added to the business machine 112. 
Additionally, the supply management function may electronically send questionnaires to 
the user to determine supply on hand. Through the above mechanisms, the supply 
management can gauge the amount of supplies on hand to deliver to the user. In step 580, 

10 any supplies are sent to the user. In some cases, the user could indicate through the web 
interface that supphes are needed which would override any automatic determination by 
the supply management function 316. 

Referring next to FIG. 5D, a flow diagram of an embodiment of a process 
followed for a pay-in-advance contract without supplies is shown. With the pay-in- 

1 5 advance contract, the user pays service in advance that is limited to a certain amount of 
usage. For example, the user may purchase service on a scanner that expires when the 
five thousand scans have been performed. In some embodiments, there may be some 
time constrains put on that usage, for example, the service for the five thousand scans 
could expire in a year. This embodiment does not include supplies along with the service 

20 contract. Steps 522, 524, 528, 532, 534, 536, 540 largely operate as discussed in relation 
to FIG. 5A. 

Picking-up the explanation in step 582, a determination of whether the 
contracted usage has reached 85%, for example, of the total is performed. Back in step 
534 and 536, a threshold event was determined and programmed into the data capture 

25 device 116 that corresponded to 85% of contract usage. For example, the threshold event 
is triggered after 4,250 scans of a 5,000 scan contract. Although the data capture device 
116 has primary responsibility for determining the triggering of threshold events, the 
operations center 104 also tests for missed threshold events when usage is reported by the 
data capture device 116. Where 85% of contract usage has not been consumed, 

30 processing loops back to step 540 to check for service conditions again. 

Where 85% of the contract usage is detected consumed by the data capture 
device, processing continues to step 584 to determine if automatic renewals are 
authorized. If automatic renewals are authorized, the remainder of the contracted usage is 
consumed in step 538 so long as no service condition is detected. In step 586, the 

12 



electronic payment is collected by the billing function 324 from the electronic payment 
organization 132 configured by the user. A billing notification is issued in step 588 and 
processing loops back to step 534. 

Where an automatic renewal is not authorized as determined in step 584, 
5 processing continues to step 590 where an electronic solicitation for renewal is sent to the 
user. Some embodiments, may supplement the electronic solicitation with a human 
performed solicitation where there is no response to the electronic solicitation. If the user 
desires to renew the contract as determined in step 552, processing loops back to step 420 
of FIG. 4. The web interface 108 is used to select another service contract in step 420. 

10 Where no renewal is desired, the contract expires in step 578 and arrangements are made 
for the user to return the data capture device 116. 

With reference to FIG. 5E, a flow diagram of an embodiment of a process 
followed for a pay-in-advance contract with supplies is shown. To accommodate the 
provisioning of supplies, new steps 572 and 580 are added to the embodiment of FIG. 5D. 

15 In step 572, a determination is made in step 572 as to whether supplies are needed and 
any supplies are sent in step 580 as described more fiilly in relation to FIG 5C above. 

Referring next to FIG. 6, a flow diagram of an embodiment of a process 
for servicing a business machine 1 12 is shown. There are number of ways in this 
embodiment to initiate a service call, such as activating the service call button 216, 

20 automatic detection of a service condition by the data capture device 1 16 and a request 
for service from the web interface 108. In some embodiments, the user may also call a 
support line for service related issues. 

In step 516, a service call button 216 on the data capture device 1 16 is 
activated. In some embodiments, the button function is integrated into the control panel 

25 of the business machine 112. The control panel display could interact with the user using 
a diagnosis wizard to determine the type of service condition. Further, the person 
reporting the service condition could enter or verify contact information for the technician 
to use when investigating the service call. Any information gathered would be relayed 
with the service call to the WAP service terminal 124 of the technician. Further, the 

30 service call function could be password protected so that only authorized users of the 

machine 112 could initiate such a call. Regardless of whether the service call button was 
activated or the data capture device detected the service condition, processing continues 
to step 520 where any information relating to the service call or status of the business 
machine 1 12 is relayed back to the operations center 104. 

13 



Stepping back to step 504, a request for service can be made using the web 
interface 108. A wizard process may also be used to facilitate an adequate description of 
the service condition. The wizard process is just a smart system that asks questions in 
series in an attempt to diagnose the service condition. In some embodiments, forms could 
5 be used instead of or in addition to the wizard process. A query is made to the data 
capture device 1 16 by the operations server 104 for any status information or errors 
detected in step 508. The data capture device 116 relays the pertinent information back to 
the operations center 104 in step 512. 

Regardless of how the service call was initiated, a determination of the 

10 technician to act on the service call is determined in step 524. The technician database is 
queried to determine the location, availability and skill level of the technicians. In one 
embodiment, one or more technicians are pre-assigned to a particular machine 1 12 to ease 
this process and to provide a technician that may be familiar with the user and office 
location. The service call information is logged into the machine database 320 in order to 

15 have accurate status for the business machine 112. 

Once the appropriate technician is located in step 528, an electronic 
message is sent to that technician. The messaging function 308 formulates the message 
and sends the message through the wide area network 128 and wireless data center 120 to 
the WAP service terminal 124 of that technician. After reading through the message, the 

20 technician calls to the user, if necessary, for further information. Sometimes the service 
condition can be solved on the phone and sometimes further information is needed to 
determine if a part is needed, for example. Any repairs needed are performed in step 536. 
The status of the service call is recorded in the machine database 320 in step 540. 

A number of variations and modifications of the invention can also be 

25 used. For example, supply contracts are integral to service contracts in the above 

embodiments. Other embodiments could provide a supply contract with or without a 
service contract. In some embodiments, certain threshold events are defined with specific 
numbers, such as 85% of contract usage expiring. Those skilled in the art will appreciate 
that those threshold events could have any values assigned to them and are not limited to 

30 specific examples in the disclosed embodiments. 

While the principles of the invention have been described above in 
connection with specific apparatuses and methods, it is to be clearly understood that this 
description is made only by way of example and not as limitation on the scope of the 
invention. 



14 



